Kendo Grid Batch Mode Page Submit

How batch mode works

In my previous blog I demonstrated how to put the Kendo grid in batch mode and submit all CRUD operations with the grid’s built-in save button. The grid performed as needed; we were able to save all operations in the CRUD handlers. Typically, however, the gird won’t be the only component in a view; there would be other fields in the view whose values need to be committed to the database. Consider the view below. It has customer Name, Title, and Address that need to be saved along with the customer orders in the grid. The grid’s built-in “save” button (in the previous blog, not show in view here) only saves the grid’s rows, it has nothing to do with any other fields in the view; it certainly won’t postback the view to the controller. The typical thing to do here is to simply slap a submit button which postback the entire view fields to the controller and from the controller we read the fields valus and store them in the database. Well, the Kend Grid, for whaterver reason I don’t want to get into, does not postback its rows. So if you go to the postback method in the controller, you won’t be able to see the grid rows. Let me demonstrate this limitation.

Simply putting a Submit button that posts the view fields won’t completly work. The grid won’t send its rows to the controller. Let’s makes some changes to the customer info and its orders (changed customer Name, Title, Address, changed Freight in the first order, added a new order)

Click Submit —

You can see the Orders in the ViewModel are empty. I even tried to return the bound ViewModel orders and that’s null. I found sporatic mention of this limitation between in the Telerik echosystem and Stack Overflow on this issue, nothing that offered a complete solution to this limitation. I set out to provide a solution to this limitation. So do do this now we’re going to remove the grid’s Save records button and the Add three hidden fields to the view to hold added, updated, and deleted rows On the client, when pressing the submit button, capture affected rows and store them in the hidden fields In the Controller, in the Edit postback method definition, add the FormsCollection parameter Read out the values of the hidden fields from the FormsCollection parameter into variables Parse out the row values into entities Commit the entities into the database Notice that we now only need to have the Read handler in the grid; the Create, Update, and Delete handlers are not needed and should be removed so that they don’t get called asynchronously when we submit the view. All CRUD processing and commiting to the datbase is going to be handled all in tle postback Edit method.

1. Add three hidden fields to the view to hold added, updated, and deleted rows

2. On the client, when pressing the submit button, capture affected rows and store them in the hidden fields

3. In the controller, in the Edit postback method definition, add the FormsCollection parameter [AcceptVerbs("Post")] public ActionResult Edit(string lookupBtn, string submitBtn, FormCollection fc, Customer viewModel, [Bind(Prefix = "models")] IEnumerable orders) { FormsCollection fc parameter contains the hidden fields 4. Read out the row values from the FormsCollection into variables

6. Commit the entities into the database

Inspecting the FormsCollection parameter coming into the Edit method postback, we see it has the changed rows:

Why batch mode

Batch submission reduces the number of round trips to the server, gives users a chance to review everything before committing, and keeps the grid responsive since the UI never waits on a network call for every keystroke or row action.